GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Border Gateway Protocol</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Border Gateway Protocol</span></h1>

</header>

</div>

<caption style="font-weight:normal;">BGP im <a href="Internetprotokollfamilie#TCP/IP-Referenzmodell" title="Internetprotokollfamilie">TCP/IP-Protokollstapel</a>:

</caption>

<td style="background:#FFCC99; color:#202122;"><b>Anwendung</b>

</td>

<td colspan="5" class="hintergrundfarbe6" style="font-weight:bold;">BGP

</td></tr>

<tr>

<td class="hintergrundfarbe8">Transport

</td>

</td></tr>

<tr>

<td class="hintergrundfarbe8">Internet

</td>

<td colspan="5"><a href="Internet_Protocol" title="Internet Protocol">IP</a> (<a href="IPv4" title="IPv4">IPv4</a>, <a href="IPv6" title="IPv6">IPv6</a>)

</td></tr>

<tr>

<td class="hintergrundfarbe8">Netzzugang

</td>

<td><a href="Ethernet" title="Ethernet">Ethernet</a>

</td>

<td><a href="Token_Bus" title="Token Bus">Token<br>Bus</a>

</td>

<td><a href="Token_Ring" title="Token Ring">Token<br>Ring</a>

</td>

</td>

<td>…

</td></tr></tbody></table>

<p>Das <b>Border Gateway Protocol</b> (<b>BGP</b>) ist das im <a href="Internet" title="Internet">Internet</a> eingesetzte <a href="Routing" title="Routing">Routingprotokoll</a>, welches <a href="Autonomes_System" title="Autonomes System">autonome Systeme</a> (AS) miteinander verbindet. Diese autonomen Systeme werden in der Regel von <a href="Internetdienstanbieter" title="Internetdienstanbieter">Internetdienstanbietern</a> gebildet. BGP wird allgemein als <a href="Exterior-Gateway-Protokoll" title="Exterior-Gateway-Protokoll">Exterior-Gateway-Protokoll</a> (EGP) und <a href="Pfadvektorprotokoll" title="Pfadvektorprotokoll">Pfadvektorprotokoll</a> bezeichnet und verwendet für Routing-Entscheidungen sowohl strategische als auch technisch-metrische Kriterien, wobei in der Praxis meist betriebswirtschaftliche Aspekte berücksichtigt werden. Innerhalb autonomer Systeme werden <a href="Interior_Gateway_Protocol" title="Interior Gateway Protocol">Interior Gateway Protokolle</a> (IGP) wie z. B. <a href="Open_Shortest_Path_First" title="Open Shortest Path First">OSPF</a> eingesetzt.

</p>

<div class="mw-heading mw-heading2"><h2 id="Protokollbeschreibung">Protokollbeschreibung</h2></div>

<p>BGP ist in RFC 1163 beschrieben.<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> In der derzeit eingesetzten Version 4 ist es im RFC 4271 beschrieben.<sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> Die BGP-Router verwenden den TCP-Port 179.

</p><p>1991 wurde im RFC 1269<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> die <i>Border Gateway Protocol (Version 3) <a href="Management_Information_Base" title="Management Information Base">MIB</a></i> veröffentlicht. Diese MIB ermöglicht das Management von Geräten mittels <a href="Simple_Network_Management_Protocol" title="Simple Network Management Protocol">SNMP</a>, die das BGP-Protokoll als <i>Autonomous System Routing Protocol</i> unterstützen.

</p><p>Im Februar 1998 wurde das BGPv4 in RFC 2283<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup> mit sogenannten <i>Multiprotocol Extensions</i> versehen. Die aktuelle Version findet sich in RFC 4760.<sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup> Damit ist BGPv4 nicht mehr rein IPv4-spezifisch, sondern unterstützt ebenso das Routing mit weiteren Protokollen der Vermittlungsschicht. U. a. ist so auch der Austausch von <a href="Multiprotocol_Label_Switching" title="Multiprotocol Label Switching">MPLS</a>-Labels möglich, dies war Voraussetzung für den Einsatz von <i>BGP/MPLS IP VPNs</i> (RFC 4364).<sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Anwendungsbereich">Anwendungsbereich</h2></div>

<p>BGP, das derzeit einzige eingesetzte <a href="Exterior-Gateway-Protokoll" title="Exterior-Gateway-Protokoll">Exterior-Gateway-Protokoll</a>, ist ein <a href="Netzwerkprotokoll" title="Netzwerkprotokoll">Protokoll</a> für das Routing zwischen <a href="Autonomes_System" title="Autonomes System">autonomen Systemen</a> (AS). Man spricht bei dieser Verwendung von <i>External BGP</i> (EBGP).

</p>

<div class="mw-heading mw-heading4"><h4 id="Route_Server">Route Server</h4></div>

<p>An Internet Exchanges, zum Beispiel dem deutschen <a href="German_Commercial_Internet_Exchange" class="mw-redirect" title="German Commercial Internet Exchange">DE-CIX</a>, treffen viele autonome Systeme zum Zwecke des <a href="Peering" title="Peering">Peerings</a> zusammen. Um die Notwendigkeit sehr vieler BGP-Verbindungen bis hin zur Vollvermaschung zu vermeiden, werden dort in der Regel sogenannte <i>Route Server</i> angeboten. Die Border-Router, die zu den angeschlossenen Netzen vermitteln, senden ihre Routen an den Routing-Server, also den <i>Route Reflector</i>, von dem alle anderen Router diese Routen wieder beziehen können. Dadurch kann ein Netzwerk auf einfache Art und Weise mit fast allen angeschlossenen Netzen <a href="Peering" title="Peering">zusammengeschlossen</a> werden.

</p>

<p>BGP kann auch innerhalb eines autonomen Systems angewendet werden. Typischerweise geschieht dies, um die von EBGP-Routern gelernten Routen innerhalb des eigenen autonomen Systems zu propagieren. Zwar wäre es auch mit Hilfe eines IGP möglich, die BGP-Attribute (siehe unten) zu übermitteln, jedoch sind diese nicht dafür ausgelegt. Diese Verwendung wird als <i>Internal BGP</i> (IBGP) bezeichnet. Alle IBGP-Router, die zusammen Routen austauschen, verwenden dieselbe AS-Nummer des eigenen AS, wenn keine BGP-Confederations (siehe unten) verwendet werden.

</p>

<div class="mw-heading mw-heading4"><h4 id="Vollständige_Vermaschung"><span id="Vollst.C3.A4ndige_Vermaschung"></span>Vollständige Vermaschung</h4></div>

<p>Beim Einsatz innerhalb eines autonomen Systems müssen BGP-Verbindungen zwischen <i>allen</i> Routern des AS eingerichtet werden, so dass eine vollständige <a href="Vermaschtes_Netz" title="Vermaschtes Netz">Vermaschung</a> entsteht. Enthält ein autonomes System <i>n</i> Router, so resultiert dies also in <span class="mwe-math-element mwe-math-element-inline"><span class="mwe-math-mathml-inline mwe-math-mathml-a11y" style="display: none;"><math xmlns="http://www.w3.org/1998/Math/MathML" alttext="{\displaystyle {\tfrac {n^{2}-n}{2}}}">

<mfrac>

<mrow>

<msup>

</mrow>

</msup>

</mrow>

</mfrac>

</mstyle>

</mrow>

</mstyle>

</mrow>

<annotation encoding="application/x-tex">{\displaystyle {\tfrac {n^{2}-n}{2}}}</annotation>

</semantics>

</math></span><img src="./_assets_/eb734a37dd21ce173a46342d1cc64c92/a58bc6b4de696d9947b607b0e6bc1d0ef0c75a7a.svg" class="mwe-math-fallback-image-inline mw-invert skin-invert" aria-hidden="true" style="vertical-align: -1.171ex; width:4.919ex; height:4.009ex;" alt="{\displaystyle {\tfrac {n^{2}-n}{2}}}" loading="lazy"></span> BGP-Verbindungen. Aufgrund der hierdurch entstehenden Skalierungsprobleme wird bei größeren Netzwerken ein sogenannter <i>Route Reflector</i> (RR) eingesetzt. Durch diesen entfällt die Notwendigkeit einer Vollvermaschung der IBGP-Router; stattdessen bauen diese eine BGP-Verbindung zu einem oder aus Redundanzgründen zu mehreren Route-Reflektoren auf.

</p><p>Der Grund der Notwendigkeit einer vollständigen Vermaschung liegt darin, dass IBGP innerhalb eines autonomen Systems empfangene BGP-Informationen von benachbarten BGP-Routern selber nicht an andere IBGP-Router weitergibt („<a href="Split_Horizon" title="Split Horizon">Split-Horizon</a>-Prinzip“). Dies dient der Vermeidung von Routing-Schleifen.

</p>

<div class="mw-heading mw-heading4"><h4 id="Route_Reflector">Route Reflector</h4></div>

<p>Um das Problem der bei einer vollständigen Vermaschung auftretenden Vielzahl an BGP-Sessions zu lösen, können in einem AS ein oder aus Redundanzgründen mehrere BGP-Router als <i>Route Reflector</i> konfiguriert werden. So schickt jeder EBGP-Router seine via EBGP gelernten Routen via IBGP nur noch an einen bestimmten BGP-Peer, den <i>Route Reflector</i>, der sie sammelt und wiederum via IBGP an die anderen BGP-Router im AS verteilt. Da nun jeder BGP-Router nur eine einzige BGP-Verbindung zu seinem <i>Route Reflector</i> zu halten braucht, fallen insgesamt nur noch <i>n</i> Verbindungen an.

</p><p>Ein einzelner <i>Route Reflector</i> stellt einen <a href="Single_Point_of_Failure" title="Single Point of Failure">Single Point of Failure</a> dar. Zur Ausfallsicherheit können daher mehrere dieser Router als Cluster zusammengeschaltet werden. Zu jedem der Cluster-Router muss von den IBGP-Routern jeweils eine Verbindung hergestellt werden. Bei <i>n</i> Routern und <i>m</i> Route-Reflektoren ergeben sich <i>n</i>·<i>m</i> Verbindungen.

</p><p>Route-Reflektoren können Router sein, die dediziert für diese Aufgabe im Netz bereitgestellt werden oder als gewöhnlicher Router im Datenpfad liegen und Route-Reflector-Funktionalität wahrnehmen<sup id="cite_ref-7" class="reference"><a href="#cite_note-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>.

</p>

<div class="mw-heading mw-heading4"><h4 id="Confederation">Confederation</h4></div>

<p>Durch <i>Confederation</i> kann ein autonomes System (AS) wiederum in autonome Systeme (Sub-AS) unterteilt werden. Diese Sub-AS erhalten unterschiedliche private <a href="Autonomes_System" title="Autonomes System">AS-Nummern</a> (ASN), für die der Bereich 64512–65535 (16-Bit-AS-Nummernbereich) bzw. 4200000000–4294967294 (32-Bit-AS-Nummernbereich)<sup id="cite_ref-8" class="reference"><a href="#cite_note-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup> reserviert und frei verfügbar ist. Es bedarf für die Nutzung dieser AS-Nummern keiner Registrierung z. B. bei der <a href="RIPE_Network_Coordination_Centre" title="RIPE Network Coordination Centre">RIPE NCC</a>. Die AS-Nummern aus diesen privaten Bereich werden von EBGP-Routern mit öffentlichen AS-Nummern nicht an andere EBGP-Router weitergeleitet. Innerhalb des AS werden somit unterschiedliche AS-Nummern verwendet, über einen öffentlichen EBGP-Router wird aber nur die externe AS-Nummer präsentiert. Zwischen den Sub-AS kommt EBGP für den Routenaustausch zum Einsatz. Zum einen kann durch den Einsatz von <i>Confederation</i> die Verwaltung großer AS vereinfacht und zum anderen die Verbindungskomplexität durch die Vollvermaschung aller IBGP-Router verringert werden.<sup id="cite_ref-9" class="reference"><a href="#cite_note-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup>

</p>

<p>In der Grafik stellen AS100 und AS200 öffentliche autonome Systeme (AS) dar, die Routen über EBGP austauschen. AS100 teilt sich durch <i>Confederation</i> in zwei private autonome System AS65050 und AS65100 auf. Die beiden privaten AS tauschen untereinander auch ihre Routen über EBGP aus. Innerhalb beider privater AS ist jeweils ein BGP-Router als <i>Route Reflector</i> (RR) konfiguriert. Alle anderen BGP-Router innerhalb eines privaten AS tauschen mit dem <i>Route Reflector</i> über IBGP ihre Routen untereinander aus.

</p>

<div class="mw-heading mw-heading4"><h4 id="Loopbackadressen">Loopbackadressen</h4></div>

<p>Im Gegensatz zu EBGP-Verbindungen, die in der Regel auf physischen Routerschnittstellen terminieren, werden IBGP-Verbindungen zwischen Router-Loopback-Adressen definiert. Hierdurch soll vermieden werden, dass bei Deaktivierung/Ausfall einer physischen Router-Schnittstelle die IBGP-Verbindung abbricht, obwohl der Router diese bei entsprechender Redundanzbereitstellung innerhalb des autonomen Systems über eine alternative Schnittstelle umschwenken könnte. Da aber ohne eine bereits bestehende IBGP-Verbindung die Loopback-Adressen als Route noch nicht propagiert werden können, ist ein darunterliegendes <a href="Interior_Gateway_Protocol" title="Interior Gateway Protocol">Interior Gateway Protocol</a> (IGP) wie z. B. OSPF erforderlich. Dies bedeutet, dass auf jedem IBGP-Router auch ein IGP-Router-Prozess konfiguriert wird. Da jeder IBGP-Router mindestens zwei physische Netzwerkkarten besitzt, wird das IGP mehrere mögliche Pfade zwischen den Loopback-Adressen kennen. Fällt nun eine physische Netzwerkschnittstelle eines IBGP-Routers aus, dann wird über IGP ein alternativer Pfad propagiert. Solange mindestens eine physische Schnittstelle erreichbar ist, ist auch die auf dem Router konfigurierte Loopback-Adresse erreichbar und die IBGP-Verbindung kann innerhalb des AS unterbrechungsfrei umgeroutet werden.

</p><p>Ohne Loopback-Adressen wären die IBGP-Router untereinander an physischen Schnittstellen gebunden. Bei einem Ausfall einer solchen Schnittstelle wäre die Verbindung unterbrochen und eine konsistente Verteilung von Routen innerhalb eines autonomen Systems selbst dann nicht mehr sichergestellt, wenn die interne Netzwerkinfrastruktur <a href="Redundanz_(Kommunikationstheorie)" title="Redundanz (Kommunikationstheorie)">redundant</a> realisiert ist.

</p>

<div class="mw-heading mw-heading2"><h2 id="Protokollübersicht"><span id="Protokoll.C3.BCbersicht"></span>Protokollübersicht</h2></div>

<p>Die direkten Verbindungen zwischen benachbarten Routern werden manuell angegeben. Router, welche miteinander über BGP Routing-Informationen austauschen wollen, bauen zunächst eine <a href="Transmission_Control_Protocol" title="Transmission Control Protocol">TCP</a>-Verbindung auf, über welche dann die BGP-Nachrichten gesendet werden. Diese Verbindung nennt man eine <i>BGP-Session</i> („Sitzung“).

</p>

<div class="mw-heading mw-heading3"><h3 id="BGP-Protokoll">BGP-Protokoll</h3></div>

<th width="8%">Bit Offset

</th>

<th colspan="16" width="46%">0–15

</th>

<th colspan="8" width="23%">16–23

</th>

<th colspan="8" width="23%">24–31

</th></tr>

<tr>

<th>0

</th>

<td rowspan="4" colspan="32" style="background:#FFCC99">Marker (16 Bytes)

</td></tr>

<tr>

<th>32

</th></tr>

<tr>

<th>64

</th></tr>

<tr>

<th>96

</th></tr>

<tr>

<th>128

</th>

<td colspan="16" style="background:#FFFF99">Message Length

</td>

<td colspan="8" style="background:#FFFF99">Message Type

</td>

</td></tr>

<tr>

<th>

</th>

<td colspan="32" style="background:#00EEEE">Message

</td></tr></tbody></table>

<ul><li><b>Marker</b>: Alle Bits der ersten 16 Bytes sind aus Kompatibilitätsgründen auf „1“ gesetzt.</li>

<li><b>Message Length</b>: Gesamtgröße der BGP-Nachricht</li>

<li><b>Message Type</b>: Art der BGP-Nachricht</li></ul>

</td></tr>

<tr>

<td>Update</td>

</td></tr>

<tr>

<td>Notification</td>

</td></tr>

<tr>

<td>KeepAlive</td>

</td></tr>

<tr>

<td>ROUTE-REFRESH</td>

</td></tr></tbody></table>

<ul><li><b>Message</b>: Bei einer Routenaktualisierung werden in diesem Bereich die Routen angegeben, welche hinzugefügt oder gelöscht wurden.</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Arten_von_BGP-Nachrichten">Arten von BGP-Nachrichten</h3></div>

<p>BGP verwendet vier verschiedene Arten von Nachrichten im Protokoll:

</p><p><b>OPEN</b><br>

Wird nur zu Beginn einer Verbindung gesendet und muss mit einer <i>KEEPALIVE</i>-Nachricht beantwortet werden. Bei der <i>OPEN</i>-Nachricht werden die Parameter BGP-Version, AS-Nummer, <i>Hold Timer</i>, <i>BGP Identifier</i> sowie optionale Parameter mitgeschickt. Danach werden die Routeninformationen zwischen den Routern ausgetauscht.

</p><p><b>UPDATE</b><br>

Teilt eine Pfadänderung mit. Es können pro <i>UPDATE</i>-Nachricht gleichzeitig mehrere Pfade hinzugefügt und mehrere entfernt werden. <i>UPDATE</i>-Nachrichten sind das Kernstück von BGP.

</p><p><b>NOTIFICATION</b><br>

Beendet eine Verbindung und gibt Fehler- bzw. Statuscodes an. Alle Pfade, die über diese beendete Verbindung empfangen wurden, müssen nun gelöscht werden. Über ein BGP-Update würde dann verbreitet werden, dass diese Route nicht mehr verfügbar ist.

</p><p><b>KEEPALIVE</b><br>

Bestätigt die <i>OPEN</i>-Anfrage. Zur regelmäßigen Überprüfung, ob der verbundene Router noch online ist oder ob die Verbindung unterbrochen ist und die Pfade über den verbundenen Router somit ungültig geworden sind. Die Router, welche gerade eine BGP-Session aufgebaut haben, senden sich gegenseitig in regelmäßigen Abständen eine <i>KEEPALIVE</i>-Nachricht. Diese besteht nur aus dem <i>Message Header</i>. Im Attribut <i>Hold Time</i> einer <i>OPEN</i>-Nachricht wird die maximale Zeit angegeben, in der ein BGP-Router eine <i>KEEPALIVE</i>-Nachricht vom BGP-Partner der Session erwartet. Kommt innerhalb der <i>Hold Time</i> keine <i>KEEPALIVE</i>-Nachricht an, wird die BGP-Session mit einer <i>NOTIFICATION</i> beendet.

</p>

<div class="mw-heading mw-heading3"><h3 id="Verbindungsstatus_bei_BGP">Verbindungsstatus bei BGP</h3></div>

<p>In der Grafik werden die verschiedenen Zustände einer BGP-Verbindung dargestellt. In der Praxis ist es wichtig zu wissen, dass noch keine Routingeinträge ausgetauscht werden, wenn in einer Routerkonfiguration der Status <i>Active</i> angezeigt wird. Dieser Status bedeutet, dass versucht wird, eine Verbindung aufzubauen. Erst wenn der Status <i>established</i> erreicht wurde, besteht eine funktionierende Verbindung zwischen den BGP-Routern.

</p>

<div class="mw-heading mw-heading2"><h2 id="Genauere_Beschreibung">Genauere Beschreibung</h2></div>

<p>Kernstück von BGP ist die <i>UPDATE</i>-Nachricht, über welche sich BGP-Router die Existenz neuer Routen (<i>Announcement</i>) oder den Wegfall bestehender Routen (<i>Withdrawal</i>) mitteilen. Der Empfänger einer <i>UPDATE</i>-Nachricht entscheidet anhand seiner Routing-Richtlinien („policies“), ob er sein Routing umstellt (und daraufhin selbst <i>UPDATE</i>-Nachrichten versenden muss), die Nachricht einfach nur weiterleitet (z. B. via IBGP) oder schlicht ignoriert.

</p>

<div class="mw-heading mw-heading3"><h3 id="Attribute">Attribute</h3></div>

<p>Eine Route in BGP hat mehrere Attribute. Im Folgenden werden die wichtigsten erklärt.

</p>

<ul><li>Der <b>AS Path</b> beschreibt, über welche autonomen Systeme das angegebene Ziel (ein <a href="Classless_Inter-Domain_Routing" title="Classless Inter-Domain Routing">CIDR</a>-Präfix) erreicht werden kann. Die autonomen Systeme werden hierbei über ihre AS-Nummer (ASN) identifiziert. Im AS-Pfad darf zwar keine Schleife vorkommen; jedoch ist es erlaubt, dass sich ein AS mehrmals hintereinander einträgt und somit den AS-Pfad künstlich verlängert, um die Route zwar verfügbar, aber unattraktiv zu machen (<i>AS Path Prepending</i>).<sup id="cite_ref-15" class="reference"><a href="#cite_note-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup></li>

<li>Die <b>IGP-Metrik</b> beschreibt die Kosten durch das eigene Netzwerk, um den Austrittspunkt in das nächste AS auf dem AS-Pfad zu erreichen.</li>

<li>Der <b>Multi-Exit Discriminator</b> (MED) wird verwendet, um verschiedene parallele Verbindungen zum gleichen Nachbar-AS zu priorisieren, bevorzugt wird der jeweils kleinste Wert. Dieses Attribut wird zwischen EBGP-Peers verwendet.</li>

<li><b>Communities</b> sind Routing Tags, anhand welcher Routing-Änderungen (UPDATE-Nachrichten) bzw. übermittelte Präfixe zu anderen BGP-Peers markiert werden können. Eine BGP-Community ist ein 32-Bit-Wert, der von anderen BGP-Routern als Filterkriterium verwendet werden kann. Neben Standard-Communities können sog. <i>Extended Communities</i> in der Notation <code>12345:12345</code> oder als Dezimalzahl frei verwendet werden.</li>

<li><b>Local Preference</b> legt durch den jeweils höheren Wert einen bevorzugten Pfad aus mehreren Pfaden innerhalb des gleichen AS fest. Falls es zum gleichen Zielpräfix mehrere Routen mit gleich langen AS-Pfaden gibt, dann kann man über <i>Local Preference</i> bestimmte Routen bevorzugen; vgl. Abschnitt „Pfadauswahl“.</li>

<li><b>Next Hop</b> ist die Angabe der <a href="IP-Adresse" title="IP-Adresse">IP-Adresse</a> des Next-Hop-Routers zu einem Präfix. Der Next-Hop-Router ist derjenige Gateway-Router, welcher das eigene AS mit dem nächsten AS auf dem AS-Pfad verbindet.</li>

<li><b>Weight</b> ist ein lokales Attribut (proprietär); vgl. Abschnitt „Pfadauswahl“.</li>

<li><b>Origin</b> gibt die Quelle eines Präfixes an: <i>IGP</i>, <i>EGP</i> oder <i>Incomplete</i>.</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Pfadauswahl">Pfadauswahl</h3></div>

<p>Sehr oft kommt es vor, dass ein Router zum selben Ziel unterschiedliche Routen mitgeteilt bekommt. Die Auswahl der Route, für welche er sich letztendlich entscheidet, ist als <i>BGP Path Selection Process</i> bekannt. Der Netzwerkbetreiber kann die Pfadauswahl im Router durch die Wahl geeigneter Regeln im Router steuern und beeinflussen.

</p><p>Grundsätzlich läuft der <i>BGP Path Selection Process</i> nach folgenden Regeln ab:<sup id="cite_ref-16" class="reference"><a href="#cite_note-16"><span class="cite-bracket">[</span>16<span class="cite-bracket">]</span></a></sup>

</p>

<ol><li>Der Pfad mit dem größten Wert für <i>Weight</i> wird bevorzugt (Cisco-<a href="Propriet%C3%A4re_Software" title="Proprietäre Software">proprietär</a>).</li>

<li>Wenn der Wert für <i>Weight</i> identisch ist, wird der Wert mit der größten <i>Local Preference</i> bevorzugt.</li>

<li>Wenn die Werte für <i>Local Preference</i> gleich sind, wird der Pfad bevorzugt, der von BGP auf diesem Router generiert wurde.</li>

<li>Wenn kein Pfad auf diesem Router generiert wurde, bevorzuge den Pfad mit dem kürzesten AS_PATH-Attribut.</li>

<li>Wenn alle AS_PATH-Attribute die gleiche Länge haben, bevorzuge den niedrigsten Origin-Typ (<i>IGP</i> ist niedriger als <i>EGP</i>, <i>EGP</i> ist niedriger als <i>Incomplete</i>)</li>

<li>Wenn alle Origin-Typen gleich sind, bevorzuge den Pfad mit dem niedrigsten MED-Attribut.</li>

<li>Wenn alle Pfade den gleichen Wert für MED haben, bevorzuge externe Pfade gegenüber internen Pfaden.</li>

<li>Wenn immer noch alle Pfade die gleiche Priorität haben, bevorzuge den Pfad zum nächstgelegenen IGP-Nachbarn.</li>

<li>Sollten alle Pfade gleich sein, bevorzuge den Pfad mit der niedrigsten IP-Adresse des BGP-Peers bezogen auf die Router-ID.</li></ol>

<div class="mw-heading mw-heading3"><h3 id="Zusammenspiel_von_IBGP_mit_dem_IGP">Zusammenspiel von IBGP mit dem IGP</h3></div>

<p>Damit ein Router ein Paket an ein anderes Netz weiterleiten kann, zu welchem er keine unmittelbare Verbindung hat, ist in der Regel ein Zusammenspiel von IBGP und dem <a href="Interior_Gateway_Protocol" title="Interior Gateway Protocol">IGP</a> (dem Intradomain-Routingprotokoll, also beispielsweise <a href="Open_Shortest_Path_First" title="Open Shortest Path First">OSPF</a>, <a href="IS-IS" title="IS-IS">IS-IS</a>, <a href="Enhanced_Interior_Gateway_Routing_Protocol" title="Enhanced Interior Gateway Routing Protocol">EIGRP</a>/<a href="Interior_Gateway_Routing_Protocol" title="Interior Gateway Routing Protocol">IGRP</a>, <a href="Routing_Information_Protocol" title="Routing Information Protocol">RIP</a>) vonnöten, welches benötigt wird, um Pakete zum entsprechenden Gateway-Router weiterzuleiten. Hierzu dient das BGP-Attribut <i>Next Hop</i>.

</p><p><b>Beispiel:</b> Ein Router R<sub>1</sub> in AS1 soll ein Paket zur Zieladresse <code>10.1.2.3</code> weiterleiten. Durch eine IBGP-Update-Nachricht hat er zuvor erfahren, dass das Zielnetz <code>10.0.0.0/8</code> über das Nachbar-AS 4711 erreichbar ist. Allerdings hat R<sub>1</sub> keine unmittelbare Verbindung zu AS4711; diese Verbindung existiert nur an einem anderen Router R<sub>2</sub> (Gateway-Router). Durch das BGP-Attribut <i>Next Hop</i> kennt R<sub>1</sub> jedoch die IP-Adresse von R<sub>2</sub>. Nur anhand der Informationen des IGP kennt R<sub>1</sub> den kürzesten Pfad innerhalb von AS1 zu R<sub>2</sub> und weiß somit, zu welchem Nachbar-Router R<sub>x</sub> er das Paket schicken muss, so dass es beim Gateway-Router R<sub>2</sub> ankommt, welcher es schließlich in AS4711 weiterleiten kann.

</p><p>Die Bereitstellung von Erreichbarkeitsinformationen für das IBGP-Protokoll durch ein IGP-Protokoll ist auch zur Herstellung von IBGP-Sessions zwischen nicht unmittelbar benachbarten IBGP-Routern oder zu BGP-Route-Reflektoren notwendig.

</p>

<div class="mw-heading mw-heading2"><h2 id="Besonderheiten_bei_BGP">Besonderheiten bei BGP</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Routingschleifen">Routingschleifen</h3></div>

<p>BGP ist ein <i><a href="Pfadvektorprotokoll" title="Pfadvektorprotokoll">Pfadvektorprotokoll</a></i>. Seine Funktionsweise ist stark an <a href="Distanzvektoralgorithmus" title="Distanzvektoralgorithmus">Distanzvektoralgorithmen</a> und -protokolle wie z. B. <a href="Routing_Information_Protocol" title="Routing Information Protocol">Routing Information Protocol</a> (RIP) angelehnt, jedoch wird dem dort vorkommenden Problem der Routingschleifen effektiv vorgebeugt. Eine Routingschleife entsteht, wenn ein <a href="Internet_Protocol" title="Internet Protocol">IP</a>-Paket auf seinem Weg durch das Internet dasselbe AS mehrmals passiert. Ein BGP-Router teilt beim Senden von Routing-Informationen (UPDATE) dem Kommunikationspartner nicht nur mit, dass er einen bestimmten Abschnitt des Internets erreichen kann, sondern auch die vollständige Liste aller autonomen Systeme (AS-Path), die IP-Pakete bis zu diesem Abschnitt passieren müssen (sein eigenes AS steht dabei an erster, das Ziel-AS an letzter Stelle). Merkt der Kommunikationspartner nun, dass das AS, dem er selbst angehört, bereits in dieser Liste vorhanden ist, verwirft er die Nachricht und vermeidet so, dass eine Routing-Schleife entsteht.

</p>

<div class="mw-heading mw-heading3"><h3 id="Route_Aggregation">Route Aggregation</h3></div>

<p>Bei BGP kann jeder Router gemeinsame Routen zusammenfassen, im Gegensatz z. B. bei OSPF, auf deren Routern eine Routing-Zusammenfassung nur auf den Area Border Routern durchgeführt werden kann.

</p>

<div class="mw-heading mw-heading3"><h3 id="Link-State">Link-State</h3></div>

<p>Unterschiedliche Linkgeschwindigkeiten werden nicht berücksichtigt. Die Routen werden hauptsächlich nach der Länge (<i>AS Path</i>) und nach strategischen Aspekten ausgewählt.

</p>

<div class="mw-heading mw-heading3"><h3 id="Hop-Länge"><span id="Hop-L.C3.A4nge"></span>Hop-Länge</h3></div>

<p>Die Anzahl an (BGP-)Routern („<a href="Hop_(Netzwerktechnologie)" title="Hop (Netzwerktechnologie)">Hop</a>“) wird durch BGP als Entscheidungskriterium bei der Auswahl des besten Weges zum Ziel nicht berücksichtigt – nur die Anzahl der autonomen Systeme ist wichtig (abgesehen vom Attribut <i>IGP-Metrik</i>).

</p>

<div class="mw-heading mw-heading2"><h2 id="Probleme_bei_BGP">Probleme bei BGP</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Allgemein">Allgemein</h3></div>

<p>BGP weist prinzipbedingt eine Reihe von Schwächen auf, die in einer Minimalkonfiguration entstehen können. Die Schwächen werden jedoch in der Regel dadurch kompensiert, dass die <a href="Priorit%C3%A4t" title="Priorität">Priorisierung</a> von Pfaden Routing-Policies unterliegt, die der jeweilige Netzbetreiber steuert.

</p>

<div class="mw-heading mw-heading3"><h3 id="Wachstum_von_Routingtabellen">Wachstum von Routingtabellen</h3></div>

<p>Da jeder BGP-Router über Routeninformationen von anderen, insbesondere der benachbarten BGP-Routern verfügt, baut sich jeder BGP-Router eine Datenbank für die Routen zu allen erreichbaren autonomen Systemen auf. Die Größe der Tabelle mit den Routen-Informationen lag im Dezember 2016 bei etwa 650.000 Einträgen in ca. 56.000 autonomen Systemen.

</p>

<th>April 2011</th>

<th>April 2012</th>

<th>Dezember 2016

</th></tr>

<tr>

<th>Routingeinträge

</th>

<td>646.157

</td></tr>

<tr>

<th>Autonome Systeme

</th>

<td>56.158

</td></tr></tbody></table>

<p>Dem Wachstum der Routing-Tabellen kann in Grenzen durch <i>Route Aggregation</i> entgegengewirkt werden.

</p>

<p>Bei der Entwicklung von <a href="IPv6" title="IPv6">IPv6</a> wurde auch das Problem des Wachstums von Routingtabellen bei <a href="IPv4" title="IPv4">IPv4</a> berücksichtigt. So sind beim Einsatz von IPv6 wesentlich weniger Routing-Einträge zu erwarten.<sup id="cite_ref-18" class="reference"><a href="#cite_note-18"><span class="cite-bracket">[</span>18<span class="cite-bracket">]</span></a></sup> Zurzeit nutzen noch nicht alle Internet-Provider IPv6 und daher kann die folgende Statistik nicht direkt mit der obigen Tabelle über die IPv4-Routing-Einträge verglichen werden.

</p>

<th>April 2012</th>

<th>Dezember 2016

</th></tr>

<tr>

<th>Routingeinträge

</th>

<td>34.789

</td></tr>

<tr>

<th>Autonome Systeme

</th>

<td>12.666

</td></tr></tbody></table>

<div class="mw-heading mw-heading3"><h3 id="Lastverteilung">Lastverteilung</h3></div>

<p>BGP bringt standardmäßig keine Verfahren zur <a href="Lastverteilung_(Informatik)" title="Lastverteilung (Informatik)">Lastverteilung</a> mit. Es wird immer nur eine mögliche Route ausgewählt. Es existieren jedoch <a href="Propriet%C3%A4r" title="Proprietär">proprietäre</a> Erweiterungen, die eine Konfiguration zur Lastverteilung ermöglichen.<sup id="cite_ref-20" class="reference"><a href="#cite_note-20"><span class="cite-bracket">[</span>20<span class="cite-bracket">]</span></a></sup> Diese Erweiterungen ermöglichen im Gegensatz z. B. zu OSPF eine Lastverteilung auf unterschiedlich gewichteten Verbindungen.

</p>

<div class="mw-heading mw-heading3"><h3 id="Sicherheit">Sicherheit</h3></div>

<p>In der Grundkonfiguration ist ein BGP-Router anfällig für <a href="Spoofing" title="Spoofing">Spoofing</a>-Angriffe, durch die Angreifer Routen manipulieren können.<sup id="cite_ref-security-survey-09_21-0" class="reference"><a href="#cite_note-security-survey-09-21"><span class="cite-bracket">[</span>21<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-22" class="reference"><a href="#cite_note-22"><span class="cite-bracket">[</span>22<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-23" class="reference"><a href="#cite_note-23"><span class="cite-bracket">[</span>23<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-24" class="reference"><a href="#cite_note-24"><span class="cite-bracket">[</span>24<span class="cite-bracket">]</span></a></sup> Durch den Einsatz von Authentifizierung mit einem zwischen den BGP-Peers individuell festgelegten Passwort (basierend auf <a href="Message-Digest_Algorithm_5" title="Message-Digest Algorithm 5">MD5</a>-Hashes), kann der Datenaustausch zwischen den BGP-Routern gesichert werden. Dies erschwert Spoofing-Angriffe zwar stark, ist aber insbesondere von der Sicherheit von MD5 abhängig, welches inzwischen von Krypto-Experten als nicht mehr sicher angesehen wird.

</p><p>Weiterhin können aufgrund des Punkt-zu-Punkt-Charakters von BGP-Router-Beziehungen mittels <a href="Paketfilter" title="Paketfilter">Paketfilter</a>-Listen die erlaubten BGP-Peers entsprechend auf die zulässigen Partner eingeschränkt werden.

</p><p>Daneben wurden und werden verschiedene weitere Sicherheitsmechanismen für BGP vorgeschlagen;<sup id="cite_ref-security-survey-09_21-1" class="reference"><a href="#cite_note-security-survey-09-21"><span class="cite-bracket">[</span>21<span class="cite-bracket">]</span></a></sup> allerdings wäre es selbst bei einem flächendeckenden Einsatz vorgeschlagener Verfahren nahezu unmöglich, Angriffe, welche die Umleitung von Verkehrsströmen beabsichtigen, vollständig zu unterbinden.<sup id="cite_ref-not-secure-2010_25-0" class="reference"><a href="#cite_note-not-secure-2010-25"><span class="cite-bracket">[</span>25<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Route_Flap">Route Flap</h3></div>

<p><i>Route Flaps</i> werden von Routen verursacht, welche über längere Zeiträume hinweg immer wieder hin- und herschwanken, annonciert und wieder zurückgezogen werden.<sup id="cite_ref-26" class="reference"><a href="#cite_note-26"><span class="cite-bracket">[</span>26<span class="cite-bracket">]</span></a></sup>

Als Gegenmaßnahme bieten moderne BGP-Implementierungen ein Verfahren namens <i>Route Flap Damping</i>, welches jedoch unter bestimmten Bedingungen zu unerwünscht langen Verzögerungen bei der Weiterleitung von Routenänderungen führen kann.<sup id="cite_ref-27" class="reference"><a href="#cite_note-27"><span class="cite-bracket">[</span>27<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Update_Bursts">Update Bursts</h3></div>

<p><i>Update Bursts</i> sind plötzlich auftretende große Mengen an UPDATE-Nachrichten, oft zu miteinander nicht näher korrelierten Zielen.<sup id="cite_ref-28" class="reference"><a href="#cite_note-28"><span class="cite-bracket">[</span>28<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Besondere_Ereignisse">Besondere Ereignisse</h2></div>

<div class="mw-heading mw-heading3"><h3 id="YouTube-Blockade">YouTube-Blockade</h3></div>

<p>Im Februar 2008 wurde Pakistan Telecom durch einen Gerichtsbeschluss dazu gezwungen, <a href="YouTube" title="YouTube">YouTube</a>-Verkehr in Pakistan zu blockieren. Technisch wurde dies umgesetzt, indem eine falsche Route zum Netzwerk von YouTube in IBGP eingespeist wurde. Durch einen Konfigurationsfehler wurde diese falsche Route jedoch nicht nur in Pakistan verwendet, sondern irrtümlich auch via EBGP an andere Internetanbieter verteilt, was insbesondere in Asien zu mehrstündigen Blockaden von YouTube führte.<sup id="cite_ref-29" class="reference"><a href="#cite_note-29"><span class="cite-bracket">[</span>29<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-30" class="reference"><a href="#cite_note-30"><span class="cite-bracket">[</span>30<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Fehlkonfigurierter_BGP-Router">Fehlkonfigurierter BGP-Router</h3></div>

<p>Im Februar 2009 wurden über einen tschechischen BGP-Router zu lange AS-Pfade an öffentliche BGP-Router weitergeleitet. Einige BGP-Router hatten Probleme in der Verarbeitung dieser langen AS-Pfade, so dass es zu Beeinträchtigungen des Internetverkehrs kam. Administratoren können durch eine Konfiguration, in welche die maximale Länge des akzeptierten AS-Pfads beschränkt wird, einem solchen Problem entgegenwirken.<sup id="cite_ref-31" class="reference"><a href="#cite_note-31"><span class="cite-bracket">[</span>31<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-32" class="reference"><a href="#cite_note-32"><span class="cite-bracket">[</span>32<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Revolution_in_Ägypten_2011"><span id="Revolution_in_.C3.84gypten_2011"></span>Revolution in Ägypten 2011</h3></div>

<p>Während der <a href="Revolution_in_%C3%84gypten_2011" title="Revolution in Ägypten 2011">Revolution in Ägypten</a> wurden im Januar 2011 via BGP in wenigen Minuten ca. 3.500 Routen aller ägyptischer Internetanbieter zurückgezogen, wodurch fast ganz Ägypten vom Internet getrennt war. Auch Mobilfunkdienste und soziale Netze waren nicht mehr erreichbar. Dieses scheint der erste Fall in der Geschichte des Internets zu sein, in welchem aus politischen Gründen ein gesamtes Land vom Internet abgeschottet wurde.<sup id="cite_ref-33" class="reference"><a href="#cite_note-33"><span class="cite-bracket">[</span>33<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Softwarefehler">Softwarefehler</h3></div>

<p>Das BGP Path Attribute kann den Wert 255 annehmen. Dieses steht für Entwicklungen (development, siehe RFC 2042<sup id="cite_ref-34" class="reference"><a href="#cite_note-34"><span class="cite-bracket">[</span>34<span class="cite-bracket">]</span></a></sup>) zur Verfügung. Bereits im Jahr 2010 führte ein Experiment mit diesem Flag zu Abstürzen in einigen Routern. Bei einem neuerlichen Versuch Ende 2018 wurden wieder fehlerhaft implementierte Router gefunden.<sup id="cite_ref-35" class="reference"><a href="#cite_note-35"><span class="cite-bracket">[</span>35<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Facebook,_Instagram_und_Whatsapp"><span id="Facebook.2C_Instagram_und_Whatsapp"></span>Facebook, Instagram und Whatsapp</h3></div>

<p>Am 4. Oktober 2021 waren für ca. 6 Stunden weltweit alle Dienste von <a href="Facebook" title="Facebook">Facebook</a>, <a href="Instagram" title="Instagram">Instagram</a> und <a href="Whatsapp" class="mw-redirect" title="Whatsapp">Whatsapp</a> nicht erreichbar. Dies ging auf eine fehlerhafte Konfiguration von Facebooks selbst gehosteten BGP-Routern zurück.<sup id="cite_ref-36" class="reference"><a href="#cite_note-36"><span class="cite-bracket">[</span>36<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-37" class="reference"><a href="#cite_note-37"><span class="cite-bracket">[</span>37<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Freie_Software-Implementierungen">Freie Software-Implementierungen</h2></div>

<ul><li><a href="Bird_Internet_routing_daemon" class="mw-redirect" title="Bird Internet routing daemon">Bird Internet routing daemon</a></li>

<li><a href="GNU_Zebra" title="GNU Zebra">GNU Zebra</a> (Entwicklung eingestellt)</li>

<li><a href="Quagga_(Software)" title="Quagga (Software)">Quagga</a> (Weiterentwicklung von Zebra)</li>

<li><a href="OpenBGPD" title="OpenBGPD">OpenBGPD</a></li>

<li><a href="EXtensible_Open_Router_Platform" title="EXtensible Open Router Platform">eXtensible Open Router Platform</a> (XORP)</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Looking_Glass_(Internet)" title="Looking Glass (Internet)">Looking Glass (Internet)</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Normen_und_Standards">Normen und Standards</h2></div>

<ul><li>Y. Rekhter, T. Li, S. Hares: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <style data-mw-deduplicate="TemplateStyles:r250917974">

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4271" class="extiw external" title="rfc:4271">4271</a></span></i> – <i><span lang="en">A Border Gateway Protocol 4</span></i> [Errata: RFC <a rel="nofollow" class="external text" href="https://www.rfc-editor.org/errata_search.php?rfc=4271">4271</a>]. Juli 2006 – Standard: [BGP4] (löst <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1771" class="extiw external" title="rfc:1771"><i>RFC 1771</i></a></span> ab, aktualisiert durch <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc6286" class="extiw external" title="rfc:6286"><i>RFC 6286</i></a></span>, englisch).</li>

<li>T. Bates, E. Chen, R. Chandra: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4456" class="extiw external" title="rfc:4456">4456</a></span></i> – <i><span lang="en">BGP Route Reflection: An Alternative to Full Mesh Internal BGP</span></i> [Errata: RFC <a rel="nofollow" class="external text" href="https://www.rfc-editor.org/errata_search.php?rfc=4456">4456</a>]. April 2006 – Standard: [IBGP] (löst <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2796" class="extiw external" title="rfc:2796"><i>RFC 2796</i></a></span> ab, aktualisiert durch <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7606" class="extiw external" title="rfc:7606"><i>RFC 7606</i></a></span>, englisch).</li>

<li>S. Hares, D. Hares: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4275" class="extiw external" title="rfc:4275">4275</a></span></i> – <i><span lang="en">BGP-4 MIB Implementation Survey</span></i> [Errata: RFC <a rel="nofollow" class="external text" href="https://www.rfc-editor.org/errata_search.php?rfc=4275">4275</a>]. Januar 2006 (englisch).</li>

<li>P. Traina, D. McPherson, J. Scudder: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc5065" class="extiw external" title="rfc:5065">5065</a></span></i> – <i><span lang="en">Autonomous System Confederations for BGP</span></i> [Errata: RFC <a rel="nofollow" class="external text" href="https://www.rfc-editor.org/errata_search.php?rfc=5065">5065</a>]. August 2007 – Standard: [BGP] (löst <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc3065" class="extiw external" title="rfc:3065"><i>RFC 3065</i></a></span> ab, englisch).</li>

<li>Q. Vohra, E. Chen: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4893" class="extiw external" title="rfc:4893">4893</a></span></i> – <i><span lang="en">BGP Support for Four-octet AS Number Space</span></i>. Mai 2007 (englisch).</li>

<li>C. Villamizar, R. Chandra, R. Govindan: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2439" class="extiw external" title="rfc:2439">2439</a></span></i> – <i><span lang="en">BGP Route Flap Damping</span></i> [Errata: RFC <a rel="nofollow" class="external text" href="https://www.rfc-editor.org/errata_search.php?rfc=2439">2439</a>]. November 1998 (englisch).</li>

<li>T. Bates, R. Chandra, D. Katz, Y. Rekhter: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4760" class="extiw external" title="rfc:4760">4760</a></span></i> – <i><span lang="en">Multiprotocol Extensions for BGP-4</span></i> [Errata: RFC <a rel="nofollow" class="external text" href="https://www.rfc-editor.org/errata_search.php?rfc=4760">4760</a>]. Januar 2007 – Standard: [BGP4] (löst <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2858" class="extiw external" title="rfc:2858"><i>RFC 2858</i></a></span> ab, aktualisiert durch <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7606" class="extiw external" title="rfc:7606"><i>RFC 7606</i></a></span>, englisch).</li>

<li>E. Chen, J. Scudder, P. Mohapatra, K. Patel: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7606" class="extiw external" title="rfc:7606">7606</a></span></i> – <i><span lang="en">Revised Error Handling for BGP UPDATE Messages</span></i>. August 2015 (englisch).</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<div class="sisterproject" style="margin:0.1em 0 0 0;"><div class="noresize noviewer" style="display:inline-block; line-height:10px; min-width:1.6em; text-align:center;" aria-hidden="true" role="presentation"><span class="mw-default-size" typeof="mw:File"><span title="Commons"></span></span></div><b><span class=""><a class="external text" href="https://commons.wikimedia.org/wiki/Category:Border_Gateway_Protocol?uselang=de"><span lang="en">Commons</span>: Border Gateway Protocol</a></span></b> – Sammlung von Bildern, Videos und Audiodateien</div>

<ul><li><a rel="nofollow" class="external text" href="https://stat.ripe.net/special/bgplay">BGPlay</a> – Ein Java-Programm zur grafischen Darstellung von BGP-Routingaktivitäten</li>

<li><a rel="nofollow" class="external text" href="https://bgp.he.net/">BGP Toolkit</a> Analyse autonomer Systeme</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1163" class="extiw external" title="rfc:1163">1163</a></span></i> – <i><span lang="en">A Border Gateway Protocol (BGP)</span></i>. Juni 1990 (englisch).</span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><a href="#cite_ref-2">↑</a></span> <span class="reference-text">Y. Rekhter, T. Li, S. Hares: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4271" class="extiw external" title="rfc:4271">4271</a></span></i> – <i><span lang="en">A Border Gateway Protocol 4</span></i> [Errata: RFC <a rel="nofollow" class="external text" href="https://www.rfc-editor.org/errata_search.php?rfc=4271">4271</a>]. Juli 2006 – Standard: [BGP4] (löst <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1771" class="extiw external" title="rfc:1771"><i>RFC 1771</i></a></span> ab, aktualisiert durch <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc6286" class="extiw external" title="rfc:6286"><i>RFC 6286</i></a></span>, englisch).</span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><a href="#cite_ref-3">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1269" class="extiw external" title="rfc:1269">1269</a></span></i> – <i><span lang="en">Definitions of Managed Objects for the Border Gateway Protocol (Version 3)</span></i>. Oktober 1991 (englisch).</span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><a href="#cite_ref-4">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2283" class="extiw external" title="rfc:2283">2283</a></span></i> – <i><span lang="en">Multiprotocol Extensions for BGP-4</span></i>. Februar 1998 (englisch).</span>

</li>

<li id="cite_note-5"><span class="mw-cite-backlink"><a href="#cite_ref-5">↑</a></span> <span class="reference-text">T. Bates, R. Chandra, D. Katz, Y. Rekhter: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4760" class="extiw external" title="rfc:4760">4760</a></span></i> – <i><span lang="en">Multiprotocol Extensions for BGP-4</span></i> [Errata: RFC <a rel="nofollow" class="external text" href="https://www.rfc-editor.org/errata_search.php?rfc=4760">4760</a>]. Januar 2007 – Standard: [BGP4] (löst <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2858" class="extiw external" title="rfc:2858"><i>RFC 2858</i></a></span> ab, aktualisiert durch <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7606" class="extiw external" title="rfc:7606"><i>RFC 7606</i></a></span>, englisch).</span>

</li>

<li id="cite_note-6"><span class="mw-cite-backlink"><a href="#cite_ref-6">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4364" class="extiw external" title="rfc:4364">4364</a></span></i> – <i><span lang="en">BGP/MPLS IP Virtual Private Networks (VPNs)</span></i>. Februar 2006 (englisch).</span>

</li>

<li id="cite_note-7"><span class="mw-cite-backlink"><a href="#cite_ref-7">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="http://www.cisco.com/c/dam/en_us/training-events/le31/le46/cln/qlm/CCIP/bgp/introducing-route-reflectors-2/player.html"><i>Introducing Route Reflectors.</i></a> Cisco,<span class="Abrufdatum"> abgerufen am 18. Mai 2017</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ABorder+Gateway+Protocol&rft.title=Introducing+Route+Reflectors&rft.description=Introducing+Route+Reflectors&rft.identifier=http%3A%2F%2Fwww.cisco.com%2Fc%2Fdam%2Fen_us%2Ftraining-events%2Fle31%2Fle46%2Fcln%2Fqlm%2FCCIP%2Fbgp%2Fintroducing-route-reflectors-2%2Fplayer.html&rft.publisher=Cisco&rft.date=&rft.language=en"> </span></span>

</li>

<li id="cite_note-8"><span class="mw-cite-backlink"><a href="#cite_ref-8">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.iana.org/assignments/as-numbers/as-numbers.xhtml"><i>Autonomous System (AS) Numbers.</i></a> IANA,<span class="Abrufdatum"> abgerufen am 1. Mai 2017</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ABorder+Gateway+Protocol&rft.title=Autonomous+System+%28AS%29+Numbers&rft.description=Autonomous+System+%28AS%29+Numbers&rft.identifier=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fas-numbers%2Fas-numbers.xhtml&rft.publisher=IANA&rft.date="> </span></span>

</li>

<li id="cite_note-9"><span class="mw-cite-backlink"><a href="#cite_ref-9">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#bgpconfed">Cisco-Referenz zu BGP Confederation</a> (englisch)</span>

</li>

<li id="cite_note-10"><span class="mw-cite-backlink"><a href="#cite_ref-10">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4271#section-4.2" class="extiw external" title="rfc:4271">4271</a></span></i> – <i><span lang="en">A Border Gateway Protocol 4 (BGP-4)</span></i>. Juli 2006, Abschnitt 4.2: <i>OPEN Message Format</i>. (englisch).</span>

</li>

<li id="cite_note-11"><span class="mw-cite-backlink"><a href="#cite_ref-11">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4271#section-4.3" class="extiw external" title="rfc:4271">4271</a></span></i> – <i><span lang="en">A Border Gateway Protocol 4 (BGP-4)</span></i>. Juli 2006, Abschnitt 4.3: <i>UPDATE Message Format</i>. (englisch).</span>

</li>

<li id="cite_note-12"><span class="mw-cite-backlink"><a href="#cite_ref-12">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4271#section-4.5" class="extiw external" title="rfc:4271">4271</a></span></i> – <i><span lang="en">A Border Gateway Protocol 4 (BGP-4)</span></i>. Juli 2006, Abschnitt 4.5: <i>NOTIFICATION Message Format</i>. (englisch).</span>

</li>

<li id="cite_note-13"><span class="mw-cite-backlink"><a href="#cite_ref-13">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4271#section-4.4" class="extiw external" title="rfc:4271">4271</a></span></i> – <i><span lang="en">A Border Gateway Protocol 4 (BGP-4)</span></i>. Juli 2006, Abschnitt 4.4: <i>KEEPALIVE Message Format</i>. (englisch).</span>

</li>

<li id="cite_note-14"><span class="mw-cite-backlink"><a href="#cite_ref-14">↑</a></span> <span class="reference-text">E. Chen: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2918" class="extiw external" title="rfc:2918">2918</a></span></i> – <i><span lang="en">Route Refresh Capability for BGP-4</span></i>. September 2000 – Standard: [BGP4] (aktualisiert durch <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7313" class="extiw external" title="rfc:7313"><i>RFC 7313</i></a></span>, englisch).</span>

</li>

<li id="cite_note-15"><span class="mw-cite-backlink"><a href="#cite_ref-15">↑</a></span> <span class="reference-text">cisco.com: <style data-mw-deduplicate="TemplateStyles:r261891140">

/* start https://de.wikipedia.org/ */

.mw-parser-output .webarchiv-memento a{color:inherit}

/* end https://de.wikipedia.org/ */

</style><a rel="nofollow" class="external text" href="https://web.archive.org/web/20120416035434/http://www.cisco.com/en/US/docs/ios/12_3/iproute/command/reference/ip2_s1g.html"><i>IP Routing Protocols Commands: send-lifetime through set-overload-bit</i></a> (<span class="webarchiv-memento"><a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a></span> vom 16. April 2012 im <i><a href="Internet_Archive" title="Internet Archive">Internet Archive</a></i>)</span>

</li>

<li id="cite_note-16"><span class="mw-cite-backlink"><a href="#cite_ref-16">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml#bestpath">Cisco-Referenz zu BGP Path Selection</a></span>

</li>

<li id="cite_note-17"><span class="mw-cite-backlink"><a href="#cite_ref-17">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="http://www.cidr-report.org/as2.0/">CIDR Report.</a> cidr-report.org (englisch) abgerufen am 21. Juni 2015</span>

</li>

<li id="cite_note-18"><span class="mw-cite-backlink"><a href="#cite_ref-18">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://labs.ripe.net/Members/gih/routing-ipv6-in-2011">RIPE NCC – Routing IPv6 in 2011.</a> ripe.net</span>

</li>

<li id="cite_note-19"><span class="mw-cite-backlink"><a href="#cite_ref-19">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="http://ipv6.he.net/bgpview/bgp.html">IPv6 BGP Operational Report from Hurricane Electric.</a> ipv6.he.net; abgerufen am 21. Juni 2015.</span>

</li>

<li id="cite_note-20"><span class="mw-cite-backlink"><a href="#cite_ref-20">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml"><i>IP Routing: BGP Best Path Selection Algorithm.</i></a> cisco.com</span>

</li>

<li id="cite_note-security-survey-09-21"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-security-survey-09_21-0">a</a></sup> <sup><a href="#cite_ref-security-survey-09_21-1">b</a></sup></span> <span class="reference-text">Kevin Butler, Toni Farley, Patrick McDaniel, <a href="Jennifer_Rexford" title="Jennifer Rexford">Jennifer Rexford</a>: <a rel="nofollow" class="external text" href="http://www.cs.princeton.edu/~jrex/papers/pieee09.pdf"><i>A survey of BGP security issues and solutions</i>.</a> (PDF; 1,5 MB) In: Proceedings of the IEEE, Januar 2010</span>

</li>

<li id="cite_note-22"><span class="mw-cite-backlink"><a href="#cite_ref-22">↑</a></span> <span class="reference-text">Barry Raveendran Greene: <a rel="nofollow" class="external text" href="http://www.cymru.com/Documents/barry2.pdf"><i>BGPv4 Security Risk Assessment.</i></a> (PDF; 159 kB) cymru.com</span>

</li>

<li id="cite_note-23"><span class="mw-cite-backlink"><a href="#cite_ref-23">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="http://ww2.cs.fsu.edu/~sanchez/bgp/papers/">Auflistung wissenschaftlicher Veröffentlichungen zum Thema BGP-Sicherheit</a></span>

</li>

<li id="cite_note-24"><span class="mw-cite-backlink"><a href="#cite_ref-24">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://www.heise.de/newsticker/meldung/Router-luegen-nicht-was-wenn-doch-200283.html"><i>Router lügen nicht – Was wenn doch?</i></a> heise security online, 27. August 2008.</span>

</li>

<li id="cite_note-not-secure-2010-25"><span class="mw-cite-backlink"><a href="#cite_ref-not-secure-2010_25-0">↑</a></span> <span class="reference-text">Sharon Goldberg, Michael Schapira, Peter Hummon, <a href="Jennifer_Rexford" title="Jennifer Rexford">Jennifer Rexford</a>: <a rel="nofollow" class="external text" href="http://www.cs.princeton.edu/~jrex/papers/secure-bgp10.pdf"><i>How secure are secure interdomain routing protocols?</i></a> (PDF; 384 kB) In: <i>Proceedings of the ACM SIGCOMM conference</i>, August 2010.</span>

</li>

<li id="cite_note-26"><span class="mw-cite-backlink"><a href="#cite_ref-26">↑</a></span> <span class="reference-text">C. Labovitz, G. Malan, F. Jahanian: <i>Internet routing instability.</i> <a href="Institute_of_Electrical_and_Electronics_Engineers" title="Institute of Electrical and Electronics Engineers">IEEE</a>/<a href="Association_for_Computing_Machinery" title="Association for Computing Machinery">ACM</a> Transactions on Networking, 6(5) 1998, S. 515–528.</span>

</li>

<li id="cite_note-27"><span class="mw-cite-backlink"><a href="#cite_ref-27">↑</a></span> <span class="reference-text">Zhenhai Duan, Jaideep Chandrashekar, Jeffrey Krasky, Kuai Xu, Zhi-Li Zhang: <i>Damping BGP Route Flaps</i>. Proceedings of the 23rd IEEE International Performance Computing and Communications Conference (IPCCC), 2004.</span>

</li>

<li id="cite_note-28"><span class="mw-cite-backlink"><a href="#cite_ref-28">↑</a></span> <span class="reference-text">Ke Zhang, Amy Yen, Xiaoliang Zhao, Dan Massey, S. Felix Wu, Lixia Zhang: <i>On Detection of Anomalous Routing Dynamics in BGP</i>. In: <i>LNCS NETWORKING 2004.</i> ISBN 3-540-21959-5.</span>

</li>

<li id="cite_note-29"><span class="mw-cite-backlink"><a href="#cite_ref-29">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://www.heise.de/newsticker/meldung/Pakistan-sperrt-YouTube-183414.html"><i>Pakistan sperrt YouTube</i>.</a> heise.de</span>

</li>

<li id="cite_note-30"><span class="mw-cite-backlink"><a href="#cite_ref-30">↑</a></span> <span class="reference-text"><span class="cite">Declan McCullagh: <a rel="nofollow" class="external text" href="https://www.cnet.com/culture/how-pakistan-knocked-youtube-offline-and-how-to-make-sure-it-never-happens-again/"><i>How Pakistan knocked YouTube offline (and how to make sure it never happens again).</i></a> In: <i>CNET.</i> 25. Februar 2008,<span class="Abrufdatum"> abgerufen am 9. November 2023</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ABorder+Gateway+Protocol&rft.title=How+Pakistan+knocked+YouTube+offline+%28and+how+to+make+sure+it+never+happens+again%29&rft.description=How+Pakistan+knocked+YouTube+offline+%28and+how+to+make+sure+it+never+happens+again%29&rft.identifier=https%3A%2F%2Fwww.cnet.com%2Fculture%2Fhow-pakistan-knocked-youtube-offline-and-how-to-make-sure-it-never-happens-again%2F&rft.creator=Declan+McCullagh&rft.date=2008-02-25&rft.language=en"> </span></span>

</li>

<li id="cite_note-31"><span class="mw-cite-backlink"><a href="#cite_ref-31">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://www.heise.de/newsticker/meldung/Fehlkonfigurierter-Router-beeintraechtigt-Teile-des-Internet-196830.html">Fehlkonfigurierter Router.</a> heise.de</span>

</li>

<li id="cite_note-32"><span class="mw-cite-backlink"><a href="#cite_ref-32">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20120415073409/http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml">Reckless Driving on the Internet.</a> (<span class="webarchiv-memento"><a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a></span> vom 15. April 2012 im <i><a href="Internet_Archive" title="Internet Archive">Internet Archive</a></i>) Renesys. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20120413030501/http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml">Longer is not Always Better.</a> (<span class="webarchiv-memento"><a href="Webarchivierung#Begrifflichkeiten" title="Webarchivierung">Memento</a></span> vom 13. April 2012 im <i><a href="Internet_Archive" title="Internet Archive">Internet Archive</a></i>) Renesys.</span>

</li>

<li id="cite_note-33"><span class="mw-cite-backlink"><a href="#cite_ref-33">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://www.heise.de/newsticker/meldung/Aegypten-ist-offline-und-ohne-Mobilfunk-4-Update-1179102.html"><i>Ägypten ist offline</i>.</a> heise.de</span>

</li>

<li id="cite_note-34"><span class="mw-cite-backlink"><a href="#cite_ref-34">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2042" class="extiw external" title="rfc:2042">2042</a></span></i> – <i><span lang="en">Registering New BGP Attribute Types</span></i>. Januar 1997 (englisch).</span>

</li>

<li id="cite_note-35"><span class="mw-cite-backlink"><a href="#cite_ref-35">↑</a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://www.golem.de/news/internet-infrastruktur-fehlerhafte-router-stoppen-bgp-experiment-1902-139186.html">Fehlerhafte Router stoppen BGP-Experiment.</a> golem.de</span>

</li>

<li id="cite_note-36"><span class="mw-cite-backlink"><a href="#cite_ref-36">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.bleepingcomputer.com/news/technology/facebook-instagram-and-whatsapp-back-online-after-bgp-fix/"><i>Facebook, Instagram, and WhatsApp back online after BGP fix.</i></a><span class="Abrufdatum"> Abgerufen am 5. Oktober 2021</span> (amerikanisches Englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ABorder+Gateway+Protocol&rft.title=Facebook%2C+Instagram%2C+and+WhatsApp+back+online+after+BGP+fix&rft.description=Facebook%2C+Instagram%2C+and+WhatsApp+back+online+after+BGP+fix&rft.identifier=https%3A%2F%2Fwww.bleepingcomputer.com%2Fnews%2Ftechnology%2Ffacebook-instagram-and-whatsapp-back-online-after-bgp-fix%2F&rft.language=en-US"> </span></span>

</li>

<li id="cite_note-37"><span class="mw-cite-backlink"><a href="#cite_ref-37">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://www.heise.de/news/Grosser-Ausfall-Facebook-WhatsApp-und-Instagram-fuer-Stunden-nicht-erreichbar-6208452.html"><i>Großer Ausfall: Facebook, WhatsApp und Instagram für Stunden nicht erreichbar.</i></a> heise online,<span class="Abrufdatum"> abgerufen am 5. Oktober 2021</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ABorder+Gateway+Protocol&rft.title=Gro%C3%9Fer+Ausfall%3A+Facebook%2C+WhatsApp+und+Instagram+f%C3%BCr+Stunden+nicht+erreichbar&rft.description=Gro%C3%9Fer+Ausfall%3A+Facebook%2C+WhatsApp+und+Instagram+f%C3%BCr+Stunden+nicht+erreichbar&rft.identifier=https%3A%2F%2Fwww.heise.de%2Fnews%2FGrosser-Ausfall-Facebook-WhatsApp-und-Instagram-fuer-Stunden-nicht-erreichbar-6208452.html&rft.publisher=heise+online&rft.language=de"> </span></span>

</li>

</ol></div></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-07-29" href="https://de.wikipedia.org/wiki/?title=Border_Gateway_Protocol&oldid=258392754">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>